Merge version 6.10.2+dfsg-15+rpi1 and 6.10.2+dfsg-16 to produce 6.10.2+dfsg-16+rpi1

Merge qt6-base (6.10.2+dfsg-16) import into refs/heads/workingbranch

Enable skipping plugins search at build time.

Forwarded: not-needed

This patch sets
QT_SKIP_AUTO_PLUGIN_INCLUSION and QT_SKIP_AUTO_QML_PLUGIN_INCLUSION to ON
by default, thus avoiding unnecesary build dependencies on plugins.

The variables can still be set to OFF by the user at build time, allowing
them to find the packages if necessary. But if you need so for a Debian
package please reach the Qt maintainers first. We want to know why you
need to do so. Thanks in advance!

Gbp-Pq: Name enable_skip_plugins.patch

Change how stack grows on HPPA.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042018
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Last-Update: 2023-07-28

On HPPA stack grows upwards. This patch introduces this change for
this 3rd party code.

Gbp-Pq: Name forkfd_grow_stack_upwards_on_hppa.patch

remove RPATH/RUNPATH from examples' binaries.

Forwarded: not-needed
Last-Update: 2024-02-15

On Debian the examples are built against system's libraries, so there is no
need to set RPATH/RUNPATH.

Gbp-Pq: Name remove_rpath_from_examples.patch

cross2

Gbp-Pq: Name cross2.patch

cross

Gbp-Pq: Name cross.patch

[PATCH] cmake/QtBuildInternalsExtra.cmake.in: Patch out embedded build path.

The original build path should not be needed in the shipped package,
and causes reproducibility issues when built in different paths.

https://reproducible-builds.org/docs/build-path/

Gbp-Pq: Name build_path_embedded_qtbuildinternalsextra_cmake.patch

remove non-used privacy-breach code

Forwarded: not-needed
Last-Update: 2015-02-18

This code makes Lintian unhappy. But we are really not using it, it only
gets inserted when building the online doc.
Anyways the best way to calm down Lintian is to simply remove it.

Gbp-Pq: Name remove_privacy_breaches.diff

Add SH description

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043225
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Upstream processes archs from time to time and tends to disable those that
they do not know wether they are working or not.

SH is working on Debian, so as an intermediate measure re enable it here.

Gbp-Pq: Name Add-SH-detection.patch

[PATCH] Revert "QProcessEnvironment: simplify locking"

This reverts commit c5d6b263c204cb09db2be36826e19acb03dc24fb.

The commit being reverted assumes the mutex is only protecting 'nameMap'
and nothing else is mutable, which is false. The mutex is not only
protecting 'nameMap' but also protecting the containing value objects,
since even though the value object is accessed read-only, its
implementation mutates its internal states for 2-way conversion between
ByteArray and QString.

Commit 85e61297f7b02297641826332dbdbc845a88c34b ("restore
QProcessEnvironment shared data thread safety on unix") said that
implicit sharing together with 'mutable' is a time bomb and the bomb is
triggered by the reverted commit.

Fixes: QTBUG-142938
Pick-to: 6.8
Change-Id: I9e3234f0eb2c691eccf753a11f63fae9944bd503
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
(cherry picked from commit 080d61c020678b75ed9d5acb062ec82ba8fc402f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 62917e4b518ecaa9dc34337e30f12eaeb41e790e)

Gbp-Pq: Name upstream_Revert-QProcessEnvironment-simplify-locking.patch

[PATCH] QFileSystemEngine: handle copy_file_range() returning ENOSYS error

This shouldn't have happened, because minimum-linux_p.h would have
declared our need for a Linux kernel 4.5 or higher. I think the issue is
not the kernel, but a container wrapping the Qt application and
filtering system calls for security. If this container hasn't been
updated to know about the system call, it may cause an ENOSYS error.

Because we now handle the condition, this commit removes the 4.5 minimum
Linux version requirement from minimum-linux_p.h.

[ChangeLog][QtCore][QFile] Added a workaround to a compatibility issue
of the copy() implementation in some containerized Linux environments,
which could cause the file copy to fail with a "Function not
implemented" error. This is believed to be a bug in the container
runtime, not Qt, in that the container wrongly filtered the
copy_file_range(2) system call that the Linux kernel supports.

Fixes: QTBUG-144142
Change-Id: Iedbf805486ad79e7127dfffd22043889359563fd
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit b1b45ca4441db9e880e3a7fc7f4e8aa3af870eb6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 7b8591ac572079e59f856fb0ac7f4e3312f6dd43)

Gbp-Pq: Name upstream_QFileSystemEngine-handle-copy_file_range-returning-E.patch

[PATCH] rhi: vulkan: Fix unintentional SDR format selection

I needed to read back the swapchain image for my Vulkan RHI-enabled
QtQuick application, but it complained that
VK_FORMAT_A2R10G10B10_UNORM_PACK32 wasn't able to be read back - why?

My initial naive solution is to simply add it to the
swapchainReadbackTextureFormat function - but that wouldn't work as
there is no BGR10A2 RHI texture format and applications would unkowingly
end up with swapped channels. The actual problem came down to how we
were selecting swapchain image formats.

The first thing I changed was the hdrFormatMatchesVkSurfaceFormat
function, because that checked two formats for HDR10:
VK_FORMAT_A2B10G10R10_UNORM_PACK32 and
VK_FORMAT_A2R10G10B10_UNORM_PACK32. Checking the online Vulkan hardware
database, the BGR variant is more well-supported. Picking the RGB
variant is inevitably going to lead into the problem described before -
and should be added back when & if a new RHI texture format is
introduced.

The next thing I changed was the swapchain format selection logic,
specifically the choice for a non-sRGB SDR format. Judging by the
comments in this function and other RHIs like DX12 we *want* the default
color format of VK_FORMAT_B8G8R8A8_UNORM unless otherwise requested.
That isn't what was happening though, on my specific hardware it was
choosing VK_FORMAT_A2R10G10B10_UNORM_PACK32 - why?

It comes down to the isSrgbFormat check in the loop. Again, for the
non-SRGB SDR case the "srgbRequested" variable is always false. And when
a non-SRGB format (like the aforementioned problematic VkFormat) is
checked isSrgbFormat will return false, but I don't think that's what is
intended here. We want that for the sRGB case, but for non-SRGB SDR the
default color format is fine and that lines up with other RHIs
(see QD3D12SwapChain::chooseFormats for an example.) I checked this
inside the loop so the passthrough code is still ran on Wayland, but I
think the new logic is still sensible.

I tested this against the five usual cases I could think of and now the
format selection seems sensible:
* non-sRGB SDR chose VK_FORMAT_B8G8R8A8_UNORM
* sRGB SDR chose VK_FORMAT_R8G8B8A8_SRGB
* extended sRGB Linear chose VK_FORMAT_R16G16B16A16_SFLOAT
* HDR10 chose VK_FORMAT_A2B10G10R10_UNORM_PACK32
* Display P3 chose VK_FORMAT_R16G16B16A16_SFLOAT

Change-Id: Ie79e9fcaa1130311958b485af9b73c59d5d9a335
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 2dd1aa3678d541aef15b564b4013728ed5b0387b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit f4c5e54a8703944ec7ea005ad4de3072b86fd61f)

Gbp-Pq: Name upstream_hdr_vulkan.diff

[PATCH] freetype: Handle failing glyph rendering

When FT_Render_Glpyh fails the slot returns a bitmap containing a valid
width and height but a null buffer.

When we eventually memcpy this buffer we will crash. Existing error
handling in this method returns null on errors.

Pick-to: 6.10 6.8
Fixes: QTBUG-145310
Change-Id: I4737ab4d769b52f42bd1ef9037c8b9fd681a4ae8
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
(cherry picked from commit 1b4f4b1797bc7db3eea6ef83a34df61d7bf78e17)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Gbp-Pq: Name upstream_freetype-handle-failing-glyph-rendering.patch

[PATCH] Update sources to support OpenSSL 4

OpenSSL 4 now uses const in logical cases across its X.509 API; this
patch updates Qt's TLS backend to compile against both 3.x and 4.x.

To do this QT_OPENSSL4_CONST macro (expands to `const` on OpenSSL >= 4,
empty otherwise) is introduced for functions which changed in OpenSSL 4.

There were pre-existing functions that were already const in OpenSSL 3
but were declared without const in Qt's wrapper layer - they have now
been fixed with plain const.

ASN1_STRING was made opaque in OpenSSL 4, so replace direct access with
use of accessor functions through the wrappers.

tst_qsslcertificate: add expected output for OpenSSL 4's slightly
different extension formatting.
tst_qsslsocket::ecdhServer: lock to TLS 1.2 as OpenSSL 4 no longer
exports DH/ECDH parameters for TLS 1.3 sessions.

Fixes: QTBUG-145221
Pick-to: 6.8
Change-Id: Ic3f7d3cf00dbcb5b4cd1a299d3608a7c694a3454
Reviewed-by: Mate Barany <mate.barany@qt.io>
Reviewed-by: Jonas Kvinge <jonas@jkvinge.net>
(cherry picked from commit e806630e694d89f567cffa9c982d1f471089ecd8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Gbp-Pq: Name upstream_openssl4.patch

qt6-base (6.10.2+dfsg-16) unstable; urgency=medium

  [ Jakub Vanek ]
  * Backport patch for fixing font rendering crashes.

[dgit import unpatched qt6-base 6.10.2+dfsg-16]

Import qt6-base_6.10.2+dfsg-16.debian.tar.xz

[dgit import tarball qt6-base 6.10.2+dfsg-16 qt6-base_6.10.2+dfsg-16.debian.tar.xz]

Merge version 6.10.2+dfsg-12+rpi1 and 6.10.2+dfsg-15 to produce 6.10.2+dfsg-15+rpi1

Merge qt6-base (6.10.2+dfsg-15) import into refs/heads/workingbranch

Enable skipping plugins search at build time.

Forwarded: not-needed

This patch sets
QT_SKIP_AUTO_PLUGIN_INCLUSION and QT_SKIP_AUTO_QML_PLUGIN_INCLUSION to ON
by default, thus avoiding unnecesary build dependencies on plugins.

The variables can still be set to OFF by the user at build time, allowing
them to find the packages if necessary. But if you need so for a Debian
package please reach the Qt maintainers first. We want to know why you
need to do so. Thanks in advance!

Gbp-Pq: Name enable_skip_plugins.patch

Change how stack grows on HPPA.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042018
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Last-Update: 2023-07-28

On HPPA stack grows upwards. This patch introduces this change for
this 3rd party code.

Gbp-Pq: Name forkfd_grow_stack_upwards_on_hppa.patch

remove RPATH/RUNPATH from examples' binaries.

Forwarded: not-needed
Last-Update: 2024-02-15

On Debian the examples are built against system's libraries, so there is no
need to set RPATH/RUNPATH.

Gbp-Pq: Name remove_rpath_from_examples.patch

cross2

Gbp-Pq: Name cross2.patch

cross

Gbp-Pq: Name cross.patch

[PATCH] cmake/QtBuildInternalsExtra.cmake.in: Patch out embedded build path.

The original build path should not be needed in the shipped package,
and causes reproducibility issues when built in different paths.

https://reproducible-builds.org/docs/build-path/

Gbp-Pq: Name build_path_embedded_qtbuildinternalsextra_cmake.patch

remove non-used privacy-breach code

Forwarded: not-needed
Last-Update: 2015-02-18

This code makes Lintian unhappy. But we are really not using it, it only
gets inserted when building the online doc.
Anyways the best way to calm down Lintian is to simply remove it.

Gbp-Pq: Name remove_privacy_breaches.diff

Add SH description

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043225
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Upstream processes archs from time to time and tends to disable those that
they do not know wether they are working or not.

SH is working on Debian, so as an intermediate measure re enable it here.

Gbp-Pq: Name Add-SH-detection.patch

[PATCH] Revert "QProcessEnvironment: simplify locking"

This reverts commit c5d6b263c204cb09db2be36826e19acb03dc24fb.

The commit being reverted assumes the mutex is only protecting 'nameMap'
and nothing else is mutable, which is false. The mutex is not only
protecting 'nameMap' but also protecting the containing value objects,
since even though the value object is accessed read-only, its
implementation mutates its internal states for 2-way conversion between
ByteArray and QString.

Commit 85e61297f7b02297641826332dbdbc845a88c34b ("restore
QProcessEnvironment shared data thread safety on unix") said that
implicit sharing together with 'mutable' is a time bomb and the bomb is
triggered by the reverted commit.

Fixes: QTBUG-142938
Pick-to: 6.8
Change-Id: I9e3234f0eb2c691eccf753a11f63fae9944bd503
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
(cherry picked from commit 080d61c020678b75ed9d5acb062ec82ba8fc402f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 62917e4b518ecaa9dc34337e30f12eaeb41e790e)

Gbp-Pq: Name upstream_Revert-QProcessEnvironment-simplify-locking.patch

[PATCH] QFileSystemEngine: handle copy_file_range() returning ENOSYS error

This shouldn't have happened, because minimum-linux_p.h would have
declared our need for a Linux kernel 4.5 or higher. I think the issue is
not the kernel, but a container wrapping the Qt application and
filtering system calls for security. If this container hasn't been
updated to know about the system call, it may cause an ENOSYS error.

Because we now handle the condition, this commit removes the 4.5 minimum
Linux version requirement from minimum-linux_p.h.

[ChangeLog][QtCore][QFile] Added a workaround to a compatibility issue
of the copy() implementation in some containerized Linux environments,
which could cause the file copy to fail with a "Function not
implemented" error. This is believed to be a bug in the container
runtime, not Qt, in that the container wrongly filtered the
copy_file_range(2) system call that the Linux kernel supports.

Fixes: QTBUG-144142
Change-Id: Iedbf805486ad79e7127dfffd22043889359563fd
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit b1b45ca4441db9e880e3a7fc7f4e8aa3af870eb6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 7b8591ac572079e59f856fb0ac7f4e3312f6dd43)

Gbp-Pq: Name upstream_QFileSystemEngine-handle-copy_file_range-returning-E.patch

[PATCH] rhi: vulkan: Fix unintentional SDR format selection

I needed to read back the swapchain image for my Vulkan RHI-enabled
QtQuick application, but it complained that
VK_FORMAT_A2R10G10B10_UNORM_PACK32 wasn't able to be read back - why?

My initial naive solution is to simply add it to the
swapchainReadbackTextureFormat function - but that wouldn't work as
there is no BGR10A2 RHI texture format and applications would unkowingly
end up with swapped channels. The actual problem came down to how we
were selecting swapchain image formats.

The first thing I changed was the hdrFormatMatchesVkSurfaceFormat
function, because that checked two formats for HDR10:
VK_FORMAT_A2B10G10R10_UNORM_PACK32 and
VK_FORMAT_A2R10G10B10_UNORM_PACK32. Checking the online Vulkan hardware
database, the BGR variant is more well-supported. Picking the RGB
variant is inevitably going to lead into the problem described before -
and should be added back when & if a new RHI texture format is
introduced.

The next thing I changed was the swapchain format selection logic,
specifically the choice for a non-sRGB SDR format. Judging by the
comments in this function and other RHIs like DX12 we *want* the default
color format of VK_FORMAT_B8G8R8A8_UNORM unless otherwise requested.
That isn't what was happening though, on my specific hardware it was
choosing VK_FORMAT_A2R10G10B10_UNORM_PACK32 - why?

It comes down to the isSrgbFormat check in the loop. Again, for the
non-SRGB SDR case the "srgbRequested" variable is always false. And when
a non-SRGB format (like the aforementioned problematic VkFormat) is
checked isSrgbFormat will return false, but I don't think that's what is
intended here. We want that for the sRGB case, but for non-SRGB SDR the
default color format is fine and that lines up with other RHIs
(see QD3D12SwapChain::chooseFormats for an example.) I checked this
inside the loop so the passthrough code is still ran on Wayland, but I
think the new logic is still sensible.

I tested this against the five usual cases I could think of and now the
format selection seems sensible:
* non-sRGB SDR chose VK_FORMAT_B8G8R8A8_UNORM
* sRGB SDR chose VK_FORMAT_R8G8B8A8_SRGB
* extended sRGB Linear chose VK_FORMAT_R16G16B16A16_SFLOAT
* HDR10 chose VK_FORMAT_A2B10G10R10_UNORM_PACK32
* Display P3 chose VK_FORMAT_R16G16B16A16_SFLOAT

Change-Id: Ie79e9fcaa1130311958b485af9b73c59d5d9a335
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 2dd1aa3678d541aef15b564b4013728ed5b0387b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit f4c5e54a8703944ec7ea005ad4de3072b86fd61f)

Gbp-Pq: Name upstream_hdr_vulkan.diff

[PATCH] Update sources to support OpenSSL 4

OpenSSL 4 now uses const in logical cases across its X.509 API; this
patch updates Qt's TLS backend to compile against both 3.x and 4.x.

To do this QT_OPENSSL4_CONST macro (expands to `const` on OpenSSL >= 4,
empty otherwise) is introduced for functions which changed in OpenSSL 4.

There were pre-existing functions that were already const in OpenSSL 3
but were declared without const in Qt's wrapper layer - they have now
been fixed with plain const.

ASN1_STRING was made opaque in OpenSSL 4, so replace direct access with
use of accessor functions through the wrappers.

tst_qsslcertificate: add expected output for OpenSSL 4's slightly
different extension formatting.
tst_qsslsocket::ecdhServer: lock to TLS 1.2 as OpenSSL 4 no longer
exports DH/ECDH parameters for TLS 1.3 sessions.

Fixes: QTBUG-145221
Pick-to: 6.8
Change-Id: Ic3f7d3cf00dbcb5b4cd1a299d3608a7c694a3454
Reviewed-by: Mate Barany <mate.barany@qt.io>
Reviewed-by: Jonas Kvinge <jonas@jkvinge.net>
(cherry picked from commit e806630e694d89f567cffa9c982d1f471089ecd8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Gbp-Pq: Name upstream_openssl4.patch

qt6-base (6.10.2+dfsg-15) unstable; urgency=medium

  [ Patrick Franz ]
  * Backport patch to support OpenSSL 4 (Closes: #1138359).

[dgit import unpatched qt6-base 6.10.2+dfsg-15]

Import qt6-base_6.10.2+dfsg-15.debian.tar.xz

[dgit import tarball qt6-base 6.10.2+dfsg-15 qt6-base_6.10.2+dfsg-15.debian.tar.xz]

Merge version 6.10.2+dfsg-11+rpi1 and 6.10.2+dfsg-12 to produce 6.10.2+dfsg-12+rpi1

Merge version 6.10.2+dfsg-7+rpi1 and 6.10.2+dfsg-11 to produce 6.10.2+dfsg-11+rpi1

Merge qt6-base (6.10.2+dfsg-12) import into refs/heads/workingbranch

Enable skipping plugins search at build time.

Forwarded: not-needed

This patch sets
QT_SKIP_AUTO_PLUGIN_INCLUSION and QT_SKIP_AUTO_QML_PLUGIN_INCLUSION to ON
by default, thus avoiding unnecesary build dependencies on plugins.

The variables can still be set to OFF by the user at build time, allowing
them to find the packages if necessary. But if you need so for a Debian
package please reach the Qt maintainers first. We want to know why you
need to do so. Thanks in advance!

Gbp-Pq: Name enable_skip_plugins.patch

Change how stack grows on HPPA.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042018
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Last-Update: 2023-07-28

On HPPA stack grows upwards. This patch introduces this change for
this 3rd party code.

Gbp-Pq: Name forkfd_grow_stack_upwards_on_hppa.patch

remove RPATH/RUNPATH from examples' binaries.

Forwarded: not-needed
Last-Update: 2024-02-15

On Debian the examples are built against system's libraries, so there is no
need to set RPATH/RUNPATH.

Gbp-Pq: Name remove_rpath_from_examples.patch

cross2

Gbp-Pq: Name cross2.patch

cross

Gbp-Pq: Name cross.patch

[PATCH] cmake/QtBuildInternalsExtra.cmake.in: Patch out embedded build path.

The original build path should not be needed in the shipped package,
and causes reproducibility issues when built in different paths.

https://reproducible-builds.org/docs/build-path/

Gbp-Pq: Name build_path_embedded_qtbuildinternalsextra_cmake.patch

remove non-used privacy-breach code

Forwarded: not-needed
Last-Update: 2015-02-18

This code makes Lintian unhappy. But we are really not using it, it only
gets inserted when building the online doc.
Anyways the best way to calm down Lintian is to simply remove it.

Gbp-Pq: Name remove_privacy_breaches.diff

Add SH description

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043225
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Upstream processes archs from time to time and tends to disable those that
they do not know wether they are working or not.

SH is working on Debian, so as an intermediate measure re enable it here.

Gbp-Pq: Name Add-SH-detection.patch

[PATCH] Revert "QProcessEnvironment: simplify locking"

This reverts commit c5d6b263c204cb09db2be36826e19acb03dc24fb.

The commit being reverted assumes the mutex is only protecting 'nameMap'
and nothing else is mutable, which is false. The mutex is not only
protecting 'nameMap' but also protecting the containing value objects,
since even though the value object is accessed read-only, its
implementation mutates its internal states for 2-way conversion between
ByteArray and QString.

Commit 85e61297f7b02297641826332dbdbc845a88c34b ("restore
QProcessEnvironment shared data thread safety on unix") said that
implicit sharing together with 'mutable' is a time bomb and the bomb is
triggered by the reverted commit.

Fixes: QTBUG-142938
Pick-to: 6.8
Change-Id: I9e3234f0eb2c691eccf753a11f63fae9944bd503
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
(cherry picked from commit 080d61c020678b75ed9d5acb062ec82ba8fc402f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 62917e4b518ecaa9dc34337e30f12eaeb41e790e)

Gbp-Pq: Name upstream_Revert-QProcessEnvironment-simplify-locking.patch

[PATCH] QFileSystemEngine: handle copy_file_range() returning ENOSYS error

This shouldn't have happened, because minimum-linux_p.h would have
declared our need for a Linux kernel 4.5 or higher. I think the issue is
not the kernel, but a container wrapping the Qt application and
filtering system calls for security. If this container hasn't been
updated to know about the system call, it may cause an ENOSYS error.

Because we now handle the condition, this commit removes the 4.5 minimum
Linux version requirement from minimum-linux_p.h.

[ChangeLog][QtCore][QFile] Added a workaround to a compatibility issue
of the copy() implementation in some containerized Linux environments,
which could cause the file copy to fail with a "Function not
implemented" error. This is believed to be a bug in the container
runtime, not Qt, in that the container wrongly filtered the
copy_file_range(2) system call that the Linux kernel supports.

Fixes: QTBUG-144142
Change-Id: Iedbf805486ad79e7127dfffd22043889359563fd
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit b1b45ca4441db9e880e3a7fc7f4e8aa3af870eb6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 7b8591ac572079e59f856fb0ac7f4e3312f6dd43)

Gbp-Pq: Name upstream_QFileSystemEngine-handle-copy_file_range-returning-E.patch

[PATCH] rhi: vulkan: Fix unintentional SDR format selection

I needed to read back the swapchain image for my Vulkan RHI-enabled
QtQuick application, but it complained that
VK_FORMAT_A2R10G10B10_UNORM_PACK32 wasn't able to be read back - why?

My initial naive solution is to simply add it to the
swapchainReadbackTextureFormat function - but that wouldn't work as
there is no BGR10A2 RHI texture format and applications would unkowingly
end up with swapped channels. The actual problem came down to how we
were selecting swapchain image formats.

The first thing I changed was the hdrFormatMatchesVkSurfaceFormat
function, because that checked two formats for HDR10:
VK_FORMAT_A2B10G10R10_UNORM_PACK32 and
VK_FORMAT_A2R10G10B10_UNORM_PACK32. Checking the online Vulkan hardware
database, the BGR variant is more well-supported. Picking the RGB
variant is inevitably going to lead into the problem described before -
and should be added back when & if a new RHI texture format is
introduced.

The next thing I changed was the swapchain format selection logic,
specifically the choice for a non-sRGB SDR format. Judging by the
comments in this function and other RHIs like DX12 we *want* the default
color format of VK_FORMAT_B8G8R8A8_UNORM unless otherwise requested.
That isn't what was happening though, on my specific hardware it was
choosing VK_FORMAT_A2R10G10B10_UNORM_PACK32 - why?

It comes down to the isSrgbFormat check in the loop. Again, for the
non-SRGB SDR case the "srgbRequested" variable is always false. And when
a non-SRGB format (like the aforementioned problematic VkFormat) is
checked isSrgbFormat will return false, but I don't think that's what is
intended here. We want that for the sRGB case, but for non-SRGB SDR the
default color format is fine and that lines up with other RHIs
(see QD3D12SwapChain::chooseFormats for an example.) I checked this
inside the loop so the passthrough code is still ran on Wayland, but I
think the new logic is still sensible.

I tested this against the five usual cases I could think of and now the
format selection seems sensible:
* non-sRGB SDR chose VK_FORMAT_B8G8R8A8_UNORM
* sRGB SDR chose VK_FORMAT_R8G8B8A8_SRGB
* extended sRGB Linear chose VK_FORMAT_R16G16B16A16_SFLOAT
* HDR10 chose VK_FORMAT_A2B10G10R10_UNORM_PACK32
* Display P3 chose VK_FORMAT_R16G16B16A16_SFLOAT

Change-Id: Ie79e9fcaa1130311958b485af9b73c59d5d9a335
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 2dd1aa3678d541aef15b564b4013728ed5b0387b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit f4c5e54a8703944ec7ea005ad4de3072b86fd61f)

Gbp-Pq: Name upstream_hdr_vulkan.diff

qt6-base (6.10.2+dfsg-12) unstable; urgency=medium

  * Team upload.
  * Update the symbols files from the logs of buildds.
  * Backport upstream commit 406903b6ef76b8333bcc332a2e5768953c3fddd4 to handle
    copy_file_range() returning ENOSYS (e.g. on Hurd); patch
    upstream_QFileSystemEngine-handle-copy_file_range-returning-E.patch.
    (Closes: #1133708)
  * Backport upstream commit 4b1eb34337bdbc66e0da18a7e7375ed0dd8455ec to fix
    concurrency issues in QProcessEnvironment; patch
    upstream_Revert-QProcessEnvironment-simplify-locking.patch.
    (Closes: #1123679)

[dgit import unpatched qt6-base 6.10.2+dfsg-12]

Import qt6-base_6.10.2+dfsg-12.debian.tar.xz

[dgit import tarball qt6-base 6.10.2+dfsg-12 qt6-base_6.10.2+dfsg-12.debian.tar.xz]

Merge qt6-base (6.10.2+dfsg-11) import into refs/heads/workingbranch

Enable skipping plugins search at build time.

Forwarded: not-needed

This patch sets
QT_SKIP_AUTO_PLUGIN_INCLUSION and QT_SKIP_AUTO_QML_PLUGIN_INCLUSION to ON
by default, thus avoiding unnecesary build dependencies on plugins.

The variables can still be set to OFF by the user at build time, allowing
them to find the packages if necessary. But if you need so for a Debian
package please reach the Qt maintainers first. We want to know why you
need to do so. Thanks in advance!

Gbp-Pq: Name enable_skip_plugins.patch

Change how stack grows on HPPA.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042018
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Last-Update: 2023-07-28

On HPPA stack grows upwards. This patch introduces this change for
this 3rd party code.

Gbp-Pq: Name forkfd_grow_stack_upwards_on_hppa.patch

remove RPATH/RUNPATH from examples' binaries.

Forwarded: not-needed
Last-Update: 2024-02-15

On Debian the examples are built against system's libraries, so there is no
need to set RPATH/RUNPATH.

Gbp-Pq: Name remove_rpath_from_examples.patch

cross2

Gbp-Pq: Name cross2.patch

cross

Gbp-Pq: Name cross.patch

[PATCH] cmake/QtBuildInternalsExtra.cmake.in: Patch out embedded build path.

The original build path should not be needed in the shipped package,
and causes reproducibility issues when built in different paths.

https://reproducible-builds.org/docs/build-path/

Gbp-Pq: Name build_path_embedded_qtbuildinternalsextra_cmake.patch

remove non-used privacy-breach code

Forwarded: not-needed
Last-Update: 2015-02-18

This code makes Lintian unhappy. But we are really not using it, it only
gets inserted when building the online doc.
Anyways the best way to calm down Lintian is to simply remove it.

Gbp-Pq: Name remove_privacy_breaches.diff

Add SH description

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043225
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Upstream processes archs from time to time and tends to disable those that
they do not know wether they are working or not.

SH is working on Debian, so as an intermediate measure re enable it here.

Gbp-Pq: Name Add-SH-detection.patch

[PATCH] rhi: vulkan: Fix unintentional SDR format selection

I needed to read back the swapchain image for my Vulkan RHI-enabled
QtQuick application, but it complained that
VK_FORMAT_A2R10G10B10_UNORM_PACK32 wasn't able to be read back - why?

My initial naive solution is to simply add it to the
swapchainReadbackTextureFormat function - but that wouldn't work as
there is no BGR10A2 RHI texture format and applications would unkowingly
end up with swapped channels. The actual problem came down to how we
were selecting swapchain image formats.

The first thing I changed was the hdrFormatMatchesVkSurfaceFormat
function, because that checked two formats for HDR10:
VK_FORMAT_A2B10G10R10_UNORM_PACK32 and
VK_FORMAT_A2R10G10B10_UNORM_PACK32. Checking the online Vulkan hardware
database, the BGR variant is more well-supported. Picking the RGB
variant is inevitably going to lead into the problem described before -
and should be added back when & if a new RHI texture format is
introduced.

The next thing I changed was the swapchain format selection logic,
specifically the choice for a non-sRGB SDR format. Judging by the
comments in this function and other RHIs like DX12 we *want* the default
color format of VK_FORMAT_B8G8R8A8_UNORM unless otherwise requested.
That isn't what was happening though, on my specific hardware it was
choosing VK_FORMAT_A2R10G10B10_UNORM_PACK32 - why?

It comes down to the isSrgbFormat check in the loop. Again, for the
non-SRGB SDR case the "srgbRequested" variable is always false. And when
a non-SRGB format (like the aforementioned problematic VkFormat) is
checked isSrgbFormat will return false, but I don't think that's what is
intended here. We want that for the sRGB case, but for non-SRGB SDR the
default color format is fine and that lines up with other RHIs
(see QD3D12SwapChain::chooseFormats for an example.) I checked this
inside the loop so the passthrough code is still ran on Wayland, but I
think the new logic is still sensible.

I tested this against the five usual cases I could think of and now the
format selection seems sensible:
* non-sRGB SDR chose VK_FORMAT_B8G8R8A8_UNORM
* sRGB SDR chose VK_FORMAT_R8G8B8A8_SRGB
* extended sRGB Linear chose VK_FORMAT_R16G16B16A16_SFLOAT
* HDR10 chose VK_FORMAT_A2B10G10R10_UNORM_PACK32
* Display P3 chose VK_FORMAT_R16G16B16A16_SFLOAT

Change-Id: Ie79e9fcaa1130311958b485af9b73c59d5d9a335
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 2dd1aa3678d541aef15b564b4013728ed5b0387b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit f4c5e54a8703944ec7ea005ad4de3072b86fd61f)

Gbp-Pq: Name upstream_hdr_vulkan.diff

qt6-base (6.10.2+dfsg-11) unstable; urgency=medium

  [ Sandro Knauß ]
  * Find a solution to use dh-python: Install the .rtupdate files with
    a different name for each arch to be coinstallable. (Closes: #1134675)

[dgit import unpatched qt6-base 6.10.2+dfsg-11]

Import qt6-base_6.10.2+dfsg-11.debian.tar.xz

[dgit import tarball qt6-base 6.10.2+dfsg-11 qt6-base_6.10.2+dfsg-11.debian.tar.xz]

Merge version 6.10.2+dfsg-6+rpi1 and 6.10.2+dfsg-7 to produce 6.10.2+dfsg-7+rpi1

Merge qt6-base (6.10.2+dfsg-7) import into refs/heads/workingbranch

Enable skipping plugins search at build time.

Forwarded: not-needed

This patch sets
QT_SKIP_AUTO_PLUGIN_INCLUSION and QT_SKIP_AUTO_QML_PLUGIN_INCLUSION to ON
by default, thus avoiding unnecesary build dependencies on plugins.

The variables can still be set to OFF by the user at build time, allowing
them to find the packages if necessary. But if you need so for a Debian
package please reach the Qt maintainers first. We want to know why you
need to do so. Thanks in advance!

Gbp-Pq: Name enable_skip_plugins.patch

Change how stack grows on HPPA.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042018
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Last-Update: 2023-07-28

On HPPA stack grows upwards. This patch introduces this change for
this 3rd party code.

Gbp-Pq: Name forkfd_grow_stack_upwards_on_hppa.patch

remove RPATH/RUNPATH from examples' binaries.

Forwarded: not-needed
Last-Update: 2024-02-15

On Debian the examples are built against system's libraries, so there is no
need to set RPATH/RUNPATH.

Gbp-Pq: Name remove_rpath_from_examples.patch

cross2

Gbp-Pq: Name cross2.patch

cross

Gbp-Pq: Name cross.patch

[PATCH] cmake/QtBuildInternalsExtra.cmake.in: Patch out embedded build path.

The original build path should not be needed in the shipped package,
and causes reproducibility issues when built in different paths.

https://reproducible-builds.org/docs/build-path/

Gbp-Pq: Name build_path_embedded_qtbuildinternalsextra_cmake.patch

remove non-used privacy-breach code

Forwarded: not-needed
Last-Update: 2015-02-18

This code makes Lintian unhappy. But we are really not using it, it only
gets inserted when building the online doc.
Anyways the best way to calm down Lintian is to simply remove it.

Gbp-Pq: Name remove_privacy_breaches.diff

Add SH description

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043225
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Upstream processes archs from time to time and tends to disable those that
they do not know wether they are working or not.

SH is working on Debian, so as an intermediate measure re enable it here.

Gbp-Pq: Name Add-SH-detection.patch

[PATCH] rhi: vulkan: Fix unintentional SDR format selection

I needed to read back the swapchain image for my Vulkan RHI-enabled
QtQuick application, but it complained that
VK_FORMAT_A2R10G10B10_UNORM_PACK32 wasn't able to be read back - why?

My initial naive solution is to simply add it to the
swapchainReadbackTextureFormat function - but that wouldn't work as
there is no BGR10A2 RHI texture format and applications would unkowingly
end up with swapped channels. The actual problem came down to how we
were selecting swapchain image formats.

The first thing I changed was the hdrFormatMatchesVkSurfaceFormat
function, because that checked two formats for HDR10:
VK_FORMAT_A2B10G10R10_UNORM_PACK32 and
VK_FORMAT_A2R10G10B10_UNORM_PACK32. Checking the online Vulkan hardware
database, the BGR variant is more well-supported. Picking the RGB
variant is inevitably going to lead into the problem described before -
and should be added back when & if a new RHI texture format is
introduced.

The next thing I changed was the swapchain format selection logic,
specifically the choice for a non-sRGB SDR format. Judging by the
comments in this function and other RHIs like DX12 we *want* the default
color format of VK_FORMAT_B8G8R8A8_UNORM unless otherwise requested.
That isn't what was happening though, on my specific hardware it was
choosing VK_FORMAT_A2R10G10B10_UNORM_PACK32 - why?

It comes down to the isSrgbFormat check in the loop. Again, for the
non-SRGB SDR case the "srgbRequested" variable is always false. And when
a non-SRGB format (like the aforementioned problematic VkFormat) is
checked isSrgbFormat will return false, but I don't think that's what is
intended here. We want that for the sRGB case, but for non-SRGB SDR the
default color format is fine and that lines up with other RHIs
(see QD3D12SwapChain::chooseFormats for an example.) I checked this
inside the loop so the passthrough code is still ran on Wayland, but I
think the new logic is still sensible.

I tested this against the five usual cases I could think of and now the
format selection seems sensible:
* non-sRGB SDR chose VK_FORMAT_B8G8R8A8_UNORM
* sRGB SDR chose VK_FORMAT_R8G8B8A8_SRGB
* extended sRGB Linear chose VK_FORMAT_R16G16B16A16_SFLOAT
* HDR10 chose VK_FORMAT_A2B10G10R10_UNORM_PACK32
* Display P3 chose VK_FORMAT_R16G16B16A16_SFLOAT

Change-Id: Ie79e9fcaa1130311958b485af9b73c59d5d9a335
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 2dd1aa3678d541aef15b564b4013728ed5b0387b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit f4c5e54a8703944ec7ea005ad4de3072b86fd61f)

Gbp-Pq: Name upstream_hdr_vulkan.diff

qt6-base (6.10.2+dfsg-7) unstable; urgency=medium

  [ Patrick Franz ]
  * Add patch to fix FTCBFS for missing qt-android-runner.py, thanks to
    Helmut Grohne (Closes: #1127020).
  * Add Breaks+Replaces for several packages against qt6-wayland
    (Closes: #1133204).

[dgit import unpatched qt6-base 6.10.2+dfsg-7]

Import qt6-base_6.10.2+dfsg-7.debian.tar.xz

[dgit import tarball qt6-base 6.10.2+dfsg-7 qt6-base_6.10.2+dfsg-7.debian.tar.xz]

Merge version 6.9.2+dfsg-4+rpi1 and 6.10.2+dfsg-6 to produce 6.10.2+dfsg-6+rpi1

Merge qt6-base (6.10.2+dfsg-6) import into refs/heads/workingbranch

Enable skipping plugins search at build time.

Forwarded: not-needed

This patch sets
QT_SKIP_AUTO_PLUGIN_INCLUSION and QT_SKIP_AUTO_QML_PLUGIN_INCLUSION to ON
by default, thus avoiding unnecesary build dependencies on plugins.

The variables can still be set to OFF by the user at build time, allowing
them to find the packages if necessary. But if you need so for a Debian
package please reach the Qt maintainers first. We want to know why you
need to do so. Thanks in advance!

Gbp-Pq: Name enable_skip_plugins.patch

Change how stack grows on HPPA.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042018
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Last-Update: 2023-07-28

On HPPA stack grows upwards. This patch introduces this change for
this 3rd party code.

Gbp-Pq: Name forkfd_grow_stack_upwards_on_hppa.patch

remove RPATH/RUNPATH from examples' binaries.

Forwarded: not-needed
Last-Update: 2024-02-15

On Debian the examples are built against system's libraries, so there is no
need to set RPATH/RUNPATH.

Gbp-Pq: Name remove_rpath_from_examples.patch

cross

Gbp-Pq: Name cross.patch

[PATCH] cmake/QtBuildInternalsExtra.cmake.in: Patch out embedded build path.

The original build path should not be needed in the shipped package,
and causes reproducibility issues when built in different paths.

https://reproducible-builds.org/docs/build-path/

Gbp-Pq: Name build_path_embedded_qtbuildinternalsextra_cmake.patch

remove non-used privacy-breach code

Forwarded: not-needed
Last-Update: 2015-02-18

This code makes Lintian unhappy. But we are really not using it, it only
gets inserted when building the online doc.
Anyways the best way to calm down Lintian is to simply remove it.

Gbp-Pq: Name remove_privacy_breaches.diff

Add SH description

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043225
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Upstream processes archs from time to time and tends to disable those that
they do not know wether they are working or not.

SH is working on Debian, so as an intermediate measure re enable it here.

Gbp-Pq: Name Add-SH-detection.patch

[PATCH] rhi: vulkan: Fix unintentional SDR format selection

I needed to read back the swapchain image for my Vulkan RHI-enabled
QtQuick application, but it complained that
VK_FORMAT_A2R10G10B10_UNORM_PACK32 wasn't able to be read back - why?

My initial naive solution is to simply add it to the
swapchainReadbackTextureFormat function - but that wouldn't work as
there is no BGR10A2 RHI texture format and applications would unkowingly
end up with swapped channels. The actual problem came down to how we
were selecting swapchain image formats.

The first thing I changed was the hdrFormatMatchesVkSurfaceFormat
function, because that checked two formats for HDR10:
VK_FORMAT_A2B10G10R10_UNORM_PACK32 and
VK_FORMAT_A2R10G10B10_UNORM_PACK32. Checking the online Vulkan hardware
database, the BGR variant is more well-supported. Picking the RGB
variant is inevitably going to lead into the problem described before -
and should be added back when & if a new RHI texture format is
introduced.

The next thing I changed was the swapchain format selection logic,
specifically the choice for a non-sRGB SDR format. Judging by the
comments in this function and other RHIs like DX12 we *want* the default
color format of VK_FORMAT_B8G8R8A8_UNORM unless otherwise requested.
That isn't what was happening though, on my specific hardware it was
choosing VK_FORMAT_A2R10G10B10_UNORM_PACK32 - why?

It comes down to the isSrgbFormat check in the loop. Again, for the
non-SRGB SDR case the "srgbRequested" variable is always false. And when
a non-SRGB format (like the aforementioned problematic VkFormat) is
checked isSrgbFormat will return false, but I don't think that's what is
intended here. We want that for the sRGB case, but for non-SRGB SDR the
default color format is fine and that lines up with other RHIs
(see QD3D12SwapChain::chooseFormats for an example.) I checked this
inside the loop so the passthrough code is still ran on Wayland, but I
think the new logic is still sensible.

I tested this against the five usual cases I could think of and now the
format selection seems sensible:
* non-sRGB SDR chose VK_FORMAT_B8G8R8A8_UNORM
* sRGB SDR chose VK_FORMAT_R8G8B8A8_SRGB
* extended sRGB Linear chose VK_FORMAT_R16G16B16A16_SFLOAT
* HDR10 chose VK_FORMAT_A2B10G10R10_UNORM_PACK32
* Display P3 chose VK_FORMAT_R16G16B16A16_SFLOAT

Change-Id: Ie79e9fcaa1130311958b485af9b73c59d5d9a335
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 2dd1aa3678d541aef15b564b4013728ed5b0387b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit f4c5e54a8703944ec7ea005ad4de3072b86fd61f)

Gbp-Pq: Name upstream_hdr_vulkan.diff

qt6-base (6.10.2+dfsg-6) unstable; urgency=medium

  [ Patrick Franz ]
  * Revert moving private.pri files from qt6-base-dev to qt6-base-
    private-dev as this breaks many builds (Closes: #1131560).
  * Backport patch to fix HDR support while using the Vulkan renderer on
    certain hardware.

[dgit import unpatched qt6-base 6.10.2+dfsg-6]

Import qt6-base_6.10.2+dfsg-6.debian.tar.xz

[dgit import tarball qt6-base 6.10.2+dfsg-6 qt6-base_6.10.2+dfsg-6.debian.tar.xz]

Merge version 6.9.2+dfsg-3+rpi1 and 6.9.2+dfsg-4 to produce 6.9.2+dfsg-4+rpi1

Import qt6-base_6.10.2+dfsg.orig.tar.xz

[dgit import orig qt6-base_6.10.2+dfsg.orig.tar.xz]

Merge qt6-base (6.9.2+dfsg-4) import into refs/heads/workingbranch

Enable skipping plugins search at build time.

Forwarded: not-needed

This patch sets
QT_SKIP_AUTO_PLUGIN_INCLUSION and QT_SKIP_AUTO_QML_PLUGIN_INCLUSION to ON
by default, thus avoiding unnecesary build dependencies on plugins.

The variables can still be set to OFF by the user at build time, allowing
them to find the packages if necessary. But if you need so for a Debian
package please reach the Qt maintainers first. We want to know why you
need to do so. Thanks in advance!

Gbp-Pq: Name enable_skip_plugins.patch

Change how stack grows on HPPA.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042018
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Last-Update: 2023-07-28

On HPPA stack grows upwards. This patch introduces this change for
this 3rd party code.

Gbp-Pq: Name forkfd_grow_stack_upwards_on_hppa.patch

remove RPATH/RUNPATH from examples' binaries.

Forwarded: not-needed
Last-Update: 2024-02-15

On Debian the examples are built against system's libraries, so there is no
need to set RPATH/RUNPATH.

Gbp-Pq: Name remove_rpath_from_examples.patch

cross

Gbp-Pq: Name cross.patch

[PATCH] cmake/QtBuildInternalsExtra.cmake.in: Patch out embedded build path.

The original build path should not be needed in the shipped package,
and causes reproducibility issues when built in different paths.

https://reproducible-builds.org/docs/build-path/

Gbp-Pq: Name build_path_embedded_qtbuildinternalsextra_cmake.patch

remove non-used privacy-breach code

Forwarded: not-needed
Last-Update: 2015-02-18

This code makes Lintian unhappy. But we are really not using it, it only
gets inserted when building the online doc.
Anyways the best way to calm down Lintian is to simply remove it.

Gbp-Pq: Name remove_privacy_breaches.diff

Add SH description

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043225
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Upstream processes archs from time to time and tends to disable those that
they do not know wether they are working or not.

SH is working on Debian, so as an intermediate measure re enable it here.

Gbp-Pq: Name Add-SH-detection.patch

qt6-base (6.9.2+dfsg-4) unstable; urgency=medium

  [ Pino Toscano ]
  * The armel, mips64el, and mipsel architectures were discontinued, so:
    - drop the architectures from libqt6sql6-ibase
    - drop the architecture markers in install files, and symbols files
    - drop the patch armv4.diff, specific to armel when building Qt software
      using clang older than 17

[dgit import unpatched qt6-base 6.9.2+dfsg-4]

Import qt6-base_6.9.2+dfsg-4.debian.tar.xz

[dgit import tarball qt6-base 6.9.2+dfsg-4 qt6-base_6.9.2+dfsg-4.debian.tar.xz]

Merge version 6.8.2+dfsg-9+rpi1 and 6.9.2+dfsg-3 to produce 6.9.2+dfsg-3+rpi1

Merge qt6-base (6.9.2+dfsg-3) import into refs/heads/workingbranch